Introduction to MPTCP
Regular Transmission Control Protocol (TCP) restricts communication to a single path per session, where a TCP session can be defined as “A logical end-to-end data communication link between two applications, using TCP as protocol”. The Internet Engineering Task Force (IETF) is currently working on mechanisms that add the capability of simultaneously using multiple paths to a regular TCP session. The extensions to TCP, called “multi-path TCP” (MPTCP) are described in Request for Comments (RFC) 6824 “TCP Extensions for Multipath Operation with Multiple Addresses”. Architectural guidelines for multipath TCP development have been published in RFC 6182. RFC 6182 defines “path” as “A sequence of links between a sender and a receiver, defined in this context by a source and destination address pair”.
In many cases multiple paths exist between peers, e.g. in case one or both of the end-devices is multi-homed and/or has connectivity via more than one access technology. For example, in a Third Generation Partnership Project (3GPP) multi-access scenario, a device (3GPP User Equipment, UE) may be connected via both a 3GPP access (such as Global System for Mobile Communications, GSM, Enhanced Data rates for GSM Evolution, EDGE, Radio Access Network (GERAN), Universal Terrestrial Radio Access Network (UTRAN), or Evolved UTRAN (E-UTRAN)) and Wireless Local Area Network (WLAN) access simultaneously. The simultaneous use of these multiple paths for a TCP session would improve resource usage within the network, and improve user experience through higher throughput and improved resilience to network failure. The use of MPTCP over multiple accesses would allow the user traffic to be either routed only over one of the accesses or simultaneously over multiple accesses. It would also allow the traffic to be moved in a seamless fashion between accesses depending on coverage, radio link quality or other factors.
In regular TCP, one TCP session between two hosts corresponds to one TCP flow between those hosts, carried over a single path. In MPTCP, one TCP session between two hosts corresponds to one or more MPTCP subflows between those hosts, each carried over a path. A (sub)flow is defined by a 5-tuple (source address, source port, destination address, destination port, protocol). Thus, a TCP session accommodates a single TCP flow when regular TCP is used, and a TCP session accommodates one or more MPTCP subflows (possibly via different paths) when MPTCP is used.
As MPTCP will likely be introduced in an incremental way, there is a high risk that only one peer (also called host) supports MPTCP. To overcome this problem, an MPTCP proxy may be used. One use case may be that the MPTCP proxy is placed in the network of an operator, and that the MPTCP-capable peer is a UE controlled by the operator.
FIG. 1 illustrates the MPTCP proxy model. A single TCP session between host A and host B corresponds to one or more MPTCP subflows between host A and a proxy, and to one TCP flow between the proxy and host B. The proxy multiplexes the MPTCP subflows to a single TCP flow, and vice versa. MPTCP proxies defined by IETF in Internet-Draft “draft-hampel-mptcp-proxies-anchors”.
Architecture
FIG. 2 describes a typical architecture when two different accesses are used. This is a simplified figure of the architecture described in 3GPP Technical Specification (TS) 23.401 and 3GPP TS 23.402. The figure mainly describes the user plane parts. Furthermore, the figure shows the Long Term Evolution (LTE) architecture in the 3GPP side but other examples includes Wideband Code Division Multiple Access (WCDMA)/High Speed Packet Access (HSPA). In this case the node corresponding to the shown eNB in the context of FIG. 2 would be a Radio Network Controller (RNC), or a combined NodeB/RNC.
The UE of FIG. 2 has a dual radio, one 3GPP radio (e.g. LTE or WCDMA/HSPA) and one WLAN radio. The LTE access network comprises a radio access network (RAN) comprising one or more evolved Node B (eNB), as well as a Core Network (CN) comprising i.a. a Serving Gateway (SGW). The AC (Access Controller) is an access router in the WLAN radio access network. The UE communicates with a peer, which is located in a Packet Data Network (PDN). One example of a PDN is the Internet. The access networks provide the UE a connection to the PDN. Such a PDN connection can be seen as a virtual (e.g. Internet Protocol, IP) tunnel between the UE and the PDN. The PDN GateWay (PGW) terminates the PDN connection.
Note that the architecture of FIG. 2 is a functional architecture. The implementer of this architecture may choose to co-locate several functions in one product, or split one function into several products.
Thus, a UE can attach to the 3GPP radio access, followed by an attachment to the WLAN radio access. The attachment procedure is described in 3GPP TS 23.401 (section 5.3.2) combined with the procedure described in 3GPP TS 23.402 (section 6.2/16.2).
IP Address Used by the Proxy
There are also different alternatives for which IP address the proxy may use towards the peer that is not MPTCP-capable. This could be either the address from the PDN connection over the LTE radio access, or the address from the PDN connection over the WLAN radio access, or a new address. In the latter case, the MPTCP proxy works as a Network Address Translator (NAT) for the MPTCP traffic.
Placement of the MPTCP Proxy in the Architecture
The concept of the MPTCP proxy can only work if the UE traffic is routed via a common point. The proxy can then be placed at that common point. There are several options for architectural placement of the proxy. One alternative is to place the proxy “beyond” or “after” the PGW, i.e. within the PDN. Such placement is described in IETF Internet-Draft “MPTCP proxies and anchors”. Another alternative is to place the proxy in the PGW. Yet another alternative is to place the proxy “in front of” or “before” the PGW, e.g. in the SGW, in the eNB or in the AC. However, when the UE moves, its LTE radio connection may be handed over to a new cell. As a consequence, the UE may get served by a new eNB or a new SGW or both. If the proxy is placed in an eNB or a SGW, then a path of the TCP session is lost. The same problem arises when the UE moves and its WLAN radio connection is handed over to a new cell.